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Background of the Invention 

1 . Field of the Invention 

5 

The present invention relates generally to systems that provide for the 
shared-use of vehicles. More particularly, the invention relates to a system that 
allows one of a plurality of drivers to automatically make a reservation for a car, 
then the system controls the access and use of the car, and the return of the car, 
10 including billing. 

2. Background of the Invention 

The number of cars in cities continues to grow, placing an ever- 
15 increasing demand on a limited infrastructure of parking and roads. 
However, many of these cars are actually in use only a very small 
fraction of the time. Many drivers commute without a car by walking, 
bicycling or by public transportation, and their cars sit idle most of the 
week. Still others may commute by car, though alternative means of 
20 transportation are available, primarily because they anticipate a possible 
need for the car during the workday. These cars simply make traffic 
worse and needlessly occupy a valuable parking spot most workdays. 

Shared-use systems have been described in the prior art, however, 
current systems are inconvenient for the vehicle drivers. Using a shared vehicle 
25 must be as convenient as possible or drivers will choose to use private vehicles 
instead. The shared vehicles should be located a short walk from a driver's 
home or work which means that they should be distributed over a wide area 
rather than centrally located or located in a small number of pods. Transaction 
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time and the number of steps that are required to gain entry to the vehicle 
should be minimized. Unnecessary steps such as retrieving a key from a kiosk, 
negotiating a barrier intended to secure the vehicle, filling out forms, etc. should 
be minimized. In addition, in current systems, the vehicles are frequently not 
5 reliably available. A reservation system can enable efficient use of vehicles and 
helps ensure availability. The reservation system should enable a user to easily 
select an available vehicle and time, or allow the user to choose from 
alternatives that are similar to the desired vehicle and time. Access to vehicles 
should be secure from unauthorized users. During a reservation, access should 
10 be restricted to the reserving driver. This provides an expected level of security 
for the reserving driver and prevents a vehicle from being used without a 
""-4 reservation either maliciously or inadvertently. 

m 

' J J Several systems have been described for shared access or shared-use 

vehicles. Generally these systems describe various methods of access and 
15 monitoring vehicles and are not integrated with a reservation system. As such, 
they provide ways of sharing vehicles that are less economical and/or less 
reliable than the present invention. Nor are they very scalable, many requiring 
specialized parking facilities, communication pods, or kiosks. 

U.S. Patent Nos. 3,624,608 and 3,665,397 describe systems that do not 
20 restrict access to the vehicles or include any reservation system. These systems 
require specially-modified stations to effect data transfer to and from the in- 
vehicle systems at each parking location and specially-modified parking 
locations for vehicle security. The systems do not provide for a high degree of 
security or reliability, nor is such a system easily scaled due to the infrastructure 
25 required at each parking location. 
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U.S. Patent Nos. 5,519,260, 5,660,246 and 5,715,905 describe systems 
that are primarily concerned with vehicle monitoring and security. These 
systems do not include a reservation system. 

There are a number of systems that require a single parking area, or 
5 multiple parking locations, to have a certain amount of infrastructure. 
Examples of these systems are described in U.S. Patent Nos. 5,812,070, 
5,206,643, 5,726,885 and 5,066,853. 

U.S. Patent No. 5,289,369 discloses a system that does not require any 
infrastructure modifications to the parking locations, but because the cars are 
10 parked in random locations, the system cannot guarantee the availability of a 

4 desired vehicle. According to this system, round trips are not required, which 

y 

5 can result in an uneven distribution of vehicles, which then need to be 
~ redistributed. 

It is therefore an object of the present invention to provide a system that 
3 15 allows a number of shared-use vehicles to be used by a number of drivers. 

i 

=? 

* It is also an object to provide a system and method to access and monitor 

3 a vehicle-sharing system with an integrated reservation system. 

It is a further object of the invention to provide a shared-use vehicle 
system that is convenient for use by the driver. 

20 It is an additional object to provide a system that makes construction, 

management, and growth of a shared-use vehicle system economical. 
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Summary of the Invention 

These and other objects are attained by the invention, which comprises a 
method and system for sharing the use of one or more vehicles by a plurality of 
5 drivers. 

According to the present invention, a system for controlling 
access to a vehicle is provided. The system includes a vehicle- 
associated access control module that is located in the vehicle. This 
module allows access to the vehicle by users who have been authorized 
10 by a verification module. The verification module communicates with 
the vehicle-associated access control module over a communications 
such as the Internet or a wireless communications system. 

The verification module includes a server that stores personal 
identification information for all authorized users, and vehicle information. The 
15 server has a database that stores all reservation requests, including specific 
vehicles, dates and times, and authorizations. 

An authorized user can thus make a reservation for a specific vehicle at 
a certain date and time, and can request a pick-up and drop-off location. At the 
appointed time, the user accesses the vehicle and presents identification such as 
20 a smart card or PIN to gain access to the car. The system maintains all 

necessary information such as mileage, length of use, distance, and other such 
information, and when the user returns the car, automatically generates a bill. 

Those skilled in the art will appreciate that the methods, systems and 
software products described herein can be implemented in systems and software 
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other than the specific examples set forth herein, and such examples are 
provided by way of illustration rather than limitation. 

This specification, including the drawings attached hereto, will next 
present the invention at various levels of enabling detail, from conceptual to 
5 specific examples of implementation. 
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Brief Description of the Drawings 

5 Fig. 1 illustrates one embodiment of the vehicle access control 

system of the present invention. 

Fig. 2 shows an overview of the system. 

10 Fig. 3 shows the system from the point of view of a driver using 

the system. 

Fig. 4 shows Step A of Fig. 3 in more detail. 

15 Fig. 5 shows Step B of Fig. 3 in more detail. 

Fig. 6 shows Step C of Fig. 3 in more detail. 

Fig. 7 shows Step D of Fig. 3 in more detail. 

20 

Fig. 8 illustrates the overall system according to the preferred 
embodiment. 

Fig. 9 shows an alternate embodiment of the system. 

25 

Fig. 10 shows the vehicle-associated access control module 
system in more detail. 
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Detailed Description of the Invention 

The invention is a highly scalable and reliable automated car sharing 
system based on specially-equipped vehicles and a central resource 
5 management reservation system. The central resource management reservation 
system is highly flexible and facilitates adding and removing vehicles and 
vehicle locations, and moving vehicles between vehicle locations. An 
authorized driver can reserve any of the vehicles for an available and desired 
amount of time, and then enter and use the vehicle in a secure and reliable 

10 fashion. Each vehicle is stored in a specific location and after use is returned to 
a specific location. Vehicles are equipped with means of identifying a driver, 
means of enabling or refusing use, and means for monitoring, measuring, and 
reporting use to the central resource management reservation system. The 
central resource management reservation system also facilitates adding and 

15 subtracting drivers to the system and automatically calculating and billing 
drivers for various fees and vehicle usage charges. 

The invention is a system and method of sharing a car, or a fleet of cars, 
using a resource management reservation system. Each car is outfitted with a 
vehicle-associated access control module as described below. The main 
20 features of the system are the convenient and reliable access to shared vehicles 
via a reservation system, a means of identifying an authorized driver, a means 
for allowing or denying entry to, and use of a vehicle, and a means for 
monitoring vehicle use. 

The invention could also be used to enable a specific group of 
25 drivers, such as a family, to share access to a single vehicle in a 

controlled way. The reservation mechanism can easily incorporate a 
range of rights and privileges for different drivers while guaranteeing or 
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denying access to the vehicle. The invention may also be used to 
enable a specific group of drivers to share access to several vehicles, 
such as a corporate fleet of cars or trucks. In this case, the reservation 
and access mechanism would limit access to the corporate fleet to 
5 drivers authorized by the corporation. 

Each driver has a unique identifier. The unique identifier may be 
implemented in the system by a variety of means, including a password or a 
personal identification number. In the preferred embodiment, a personal 
identification number assigned to each driver allows secure access to the 
10 reservation system of the present invention. The unique identifier may also 
include a smart card or chip card. In the preferred embodiment, a smart card is 
used to gain access to a vehicle. 

Each of the cars in the fleet is parked in a specific location for a specific 
amount of time when not in use. A central resource management reservation 
15 system stores data and determines when and where each vehicle is parked when 
not in use, allowing each driver to reliably reserve a specific vehicle for a 
specific duration. 

Each of the cars in the fleet is equipped with a vehicle-associated access 
control module that has a means of communicating with the central resource 
20 management reservation system. The vehicle-associated access control module 
is also equipped with a means of recognizing the identity of each driver by 
using a chip card reader, in the preferred embodiment. 

Because most wireless communication mechanisms are not available 
100 % of the time due to poor coverage, environmental shielding effects, or 
25 other unforeseen conditions, the vehicle-associated access control module is 
intended to perform with partial availability of the communications link. 
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According to the preferred embodiment, a driver wishing to use 
one of the cars must first make a reservation. The driver may request a 
specific car in a specific location or one of a pool of cars in a specific 
location starting and ending at specific times. When the driver makes a 
5 reservation, the system checks the status of that particular driver and, if a 
problem exists with that user's account, notifies the user before 
continuing with the reservation process. If a requested vehicle or 
pickup location is not available, the system presents the user with 
alternate choices for the requested date and time. 

10 If the requested car is available, or if there is adequate availability within 

the pool of cars, then the reservation is confirmed. Before the start of the 
reservation, the central resource management reservation system informs the 
appropriate vehicle-associated access control module of the details of the 
reservation including the chip card ID of the driver and the start and end time of 

15 the reservation. 

At the time of the start of the reservation, the driver goes to the specific 
location and identifies himself by placing the proximity or chip card near the 
reader. If his ID matches the stored ID, then the vehicle-associated access 
control module unlocks the car door, disables the vehicle security system, 

20 enables ignition, and informs the server. The proximity or chip card is used to 
lock the car the same way it was used to unlock the car. During the reservation 
period and beyond, until a different proximity or chip card ID is detected, the 
vehicle-associated access control module permits the driver's proximity or chip 
card to be used to unlock and lock the car. At the end of the reservation, the 

25 vehicle-associated access control module informs the server of the vehicle usage 
time and distance traveled. This information permits the server to automatically 
calculate usage charges and to bill the driver's account accordingly. Because 
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the usage information is tracked automatically, the server can better manage the 
fleet of vehicles. 

The vehicle-associated access control module monitors the status of the 
wireless communications link to the server. If there is ever a problem with the 
5 server, or with the communications link to the server, then the access control 
module does not trust any reservations it might know about and it allows any 
valid proximity or chip card ID to gain access and use the vehicle. Usage is 
monitored, and when the link to the server is re-established, the usage 
information is sent to the server. Reservation information is also sent from the 
10 server to the access control module. If the access control module determines 
that the current driver is using vehicle without a valid reservation, the access 
control module can sound an alarm altering the driver. 

The vehicle-associated access control module can accept new 
instructions via the wireless communications link to the server. This permits 
15 each of these modules to be updated remotely rather than requiring a visit to 
each of the vehicles every time a modification needs to be made. 

The vehicle security system can be overridden for maintenance 
purposes, either by remote control or by special master IDs of the proximity or 
chip cards. 

20 Nearly all of the components used in the system are conventional ones 

and need no detailed description. As stated above, the main feature of the 
present invention is the convenient and reliable access to shared vehicles. 

The system provides for automated monitoring and tracking of vehicle 
use. If fees are charged for the use of the shared vehicles, bills are generated 
25 automatically from tracking data and submitted for automatic payment. 
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According to the present invention, the management of a fleet of shared 
vehicles is economical and scalable. Vehicles locations, in the preferred 
embodiment, are distributed over a wide area. The system minimizes 
infrastructure costs by completely containing the components of the system that 
5 implement the shared access and vehicle monitoring within the vehicle. This 
allows vehicles to be stored in any parking location rather than limiting storage 
to specific locations that have been built or modified for them, such as special 
parking facilities, kiosks, or barriers. It also permits vehicles to be moved to 
new parking locations and allows a large number of new vehicles to be added 
10 without the need to build any additional parking location-specific infrastructure. 

Once the system components are installed in a vehicle, they may be 
reprogrammed via a wireless connection, thus obviating the need to visit each 
vehicle. This allows for more efficient and more scalable management of 
system development and improvements. 

15 The present invention thus reduces the total number of cars in a city 

because it allows a shared vehicle to replace a number of private vehicles. The 
availability of shared-access vehicles will encourage some drivers to dispose of 
their cars, some to defer purchase of a car, and others to leave their vehicles at 
home. Drivers using shared cars will likely drive less than drivers of private 

20 vehicles because the costs of each trip are externalized and the drivers tend to 
make a rational decision each time they need to get somewhere. 

The system has a vehicle-associated access control module for enabling 
access to the vehicle by an authorized driver. The driver must first complete a 
verification sequence, showing that the driver is authorized. The system, at the 
25 zipcar.com server, has a verification module that communicates with the 
vehicle-associated access control module. The vehicle-associated access 
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control module and the remote verification module communicate over a 
communications channel. These components and the overall system are 
described in more detail below, and in conjunction with the Figures. 

Figure 1 illustrates one embodiment of the vehicle-associated access 
5 control system. The chip card reader 105, a Philips MIFARE Card Reader, 
detects a chip card and signals the Board Computer 101. The Board Computer 
101 first determines whether or not the communication link to the Zipcar.com 
server (shown in Figure 2) via GSM-GPRS wireless modem 102 and Antenna 
103 is enabled. If the communication link is enabled, the reservation data 

10 stored on the board computer are trusted and the board computer compares the 
ID of the proximity or chip card presented with the ID in each stored 
reservation. If the ID matches an appropriate reservation, the board computer 
unlocks the car door via the door locks module 107 and enables the ignition via 
the starter module 106. The display and keypad 108 can be used for further 

15 driver verification by requesting a driver-specific code be entered and compared 
before enabling the ignition. The display and keypad 108 can further be used to 
solicit information from the driver regarding the status of the vehicle and 
reservation. The display and keypad 108 can also be used to enable the driver 
to change the current reservation. The display and keypad 108 can also be used 

20 to create a new reservation if there is not one for this vehicle already. During 
use, Board Computer 101 monitors the Odometer 104. The total distance that 
was traveled during the reservation is stored for later transmission to the 
Zipcar.com server via GSM-GPRS 102 and Antenna 103. The system may also 
include a Global Position System (GPS) that allows the system to determine the 

25 location of each of the cars, both when in use and when not in use. 
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Figure 2 illustrates one embodiment of the overall system. The vehicle- 
associated access control system is contained in a plurality of cars 201 that 
communicate via wireless link through a base station 202 and a service provider 
203 that is a gateway to the Internet 208. Typically, base station 202 and 
5 service provider 203 are components in a network provided by a wireless data 
service provider such as Verizon or Omnipoint or AT&T. The client PCs 209, 
210, and 21 1 are used to access the Zipcar.com server 215 via the Internet 208 
so that vehicle availability can be reviewed and reservations created. The 
accounting office 214 is also connected to the Internet allowing accountants to 

10 review the system activity and charges. Drivers can also review their own 
account status via their own PC (represented by PCs 209, 210, and 21 1) by 
accessing the Zipcar.com server 215 though the Internet 208. The Bank 213 is a 
payment processor that permits the Zipcar.com server 215 to automatically 
charge for usage of the cars and other fees via the Credit/Debit service module 

15 207 in the Zipcar.com server 215. The Zipcar.com server 215 contains a 

database 204 that stores all the information necessary to manage the resource 
management reservation system. Web pages 205 are constructed by the 
Zipcar.com server 215 using information from the database 204 and can be 
displayed on the client PCs 208, 209, 210 via the Internet 208. The Zipcar.com 

20 server 215 can also send and receive email via the Email In/Out module 6 via 
the Internet 208. The corporate LAN 212 is connected to the Zipcar.com server 
215 via a secure link allowing office personnel to manage the server. 

Figure 3 describes the system from the point of view of the driver who 
wants to use a vehicle. As shown in Step A, the driver makes a reservation for a 
25 specific vehicle or one of a pool of vehicles parked in a specific location for a 
specific period of time. In Step B the driver goes to the specific location and 
gains access to the vehicle or one of a pool of vehicles using their proximity or 
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chip card and uses the vehicle. In Step C the driver returns the vehicle to a 
specific location. In Step D the driver is billed automatically for their use of the 
vehicle. 

Figure 4 describes the method to make a reservation (Step A of Figure 
3) in more detail. The driver's identity is verified, as shown in step 401, by any 
of various means including entering a username and password. Once the driver 
identity is verified, the zipcar.com server checks the driver account, shown in 
step 402, to make sure the driver is permitted to charge usage on the account. If 
the account is not verified, the driver may rectify whatever the problem is, such 
as enter a new credit card number, as shown in step 403. Once the driver's 
account is processed and accepted, then the driver specifies the desired location, 
start date and time, end date and time, and other optional parameters, shown in 
step 404. Individual driver preferences are stored in a database and preferences 
include the preferred city, neighborhood, location, vehicle type, and other such 
information. The system examines the individual driver's preferences to 
facilitate the selection of the desired reservation parameters, as shown in step 
404. 

As shown in step 405, the zipcar.com server checks for any available 
vehicle or vehicles that match the preferences specified. If no vehicles are 
20 available that match the preferences, alternative choices are presented to the 
driver, as shown in step 406. These alternatives are displayed ordered by the 
most likely preferred choices first, and the least likely preferred choices last. 
For example, the most likely choices may be the available vehicles nearest to 
the preferred vehicle. In this case, the locations of all vehicles are known and a 
25 well-known formula may be used to calculate the distance from the preferred 
vehicle to the available vehicles. 
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After the vehicle availability is confirmed, or an alternative vehicle is 
chosen, shown in step 406, the driver confirms the reservation, shown in step 
407. The confirmation step allows the driver to select from among several 
available vehicles that match the preferences. The driver is also able to estimate 
5 the cost of the reservation by entering anticipated usage. 

After the reservation is confirmed, the zipcar.com server establishes 
communication with the appropriate vehicle-associated access control module. 
Once this communication is established, the server transfers the reservation 
information, shown in step 409, to the vehicle-associated access control module. 

10 Figure 5 describes Step B of Figure 3 in more detail. In Figure 5, 

the driver goes to the specific location and gains access to the vehicle. 
The operations shown in Figure 5 are implemented by the vehicle- 
associated access control module. As shown in step 501 of Fig. 5, the 
driver first identifies himself to the system. In the preferred 

15 embodiment, the means of identification is a proximity card, which 
could be provided by Applied Wireless Identification Group, Inc. 
(AWID) model Prox-Linc CS or KT. In the preferred embodiment, the 
access control module is equipped with a detector, which could be 
AWID model SR2400-ZIP. According to the system, the vehicle- 

20 associated processor is in communication with a proximity card detector 
that enables access to the vehicle only when a validated proximity card 
is placed in proximity to the card detector. The vehicle-associated 
processor may include associated audio/visual display elements, such as 
a visual display or a speaker. In an alternate embodiment, the vehicle- 

25 associated processor may also include data entry elements the user 
accesses to enter authorization data, such as a keyboard or a touch- 
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screen, or other devices available to enter a user-associated personal 
identification number for validation. 

As shown in step 5 12 of Figure 5, the access control module determines 
whether the doors are locked or not. If the doors are not locked, as shown in 
5 step 513, the vehicle-associated access control module sends a signal that causes 
the doors to be locked and the ignition to be disabled. The access control 
module then returns to wait for another signal from the proximity card detector. 
If the doors are locked, as shown in step 502, the processor determines if a 
reservation has begun. 

10 If a new reservation has begun, as shown in Step 503, the ID from the 

proximity card is compared with the card ID for the current reservation. If the 
card ID matches, as shown in step 504, the processor sends a signal to the door 
unlock mechanism and enables the ignition via the Ignition Disable. If the ID 
does not match, as shown in step 505, access is refused by keeping the doors 

15 locked and the ignition remains disabled. If, as shown in step 502, the 

processor determines that a reservation has not begun, the status of the wireless 
connection via the wireless modem and antenna to the zipcar.com server is 
queried (step 506). If the connection is enabled, the reservation data stored in 
Board Computer 101 is trusted and the card ID from the proximity card is 

20 compared with the stored reservations (step 507). If the card ID matches, the 
processor records the beginning of the vehicle usage for this reservation (step 
508). The system then allows for vehicle usage, shown in step 504. If the card 
ID does not match, access is refused. 

If the system determines that the wireless connection is down, a simpler 
25 test of the card ID is performed. If the card ID is determined to be valid, the 
start of vehicle usage is logged as above. If the card ID is determined to be 
invalid, access is refused. The system may perform a further check to 
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determine if the card ID matches a list of master ID numbers permitted to access 
the vehicle at all times (shown at steps 503, 507, and 510). As shown in step 
507, a driver may be permitted access to the vehicle without a reservation. If 
the vehicle-associated access control module is equipped with a keyboard, user 
5 interface processor, and display, the driver may create a new reservation by 
entering desired information via the on-board keyboard. In certain 
embodiments, a driver is permitted access to the vehicle without a pre- 
authorized ID. In such a case, the resource management reservation system 
performs an authorization before allowing vehicle use. Such an authorization 
10 could include a background driving record check for insurance purposes and a 
credit check to determine creditworthiness. 

Figure 6 describes Step C of Figure 3 in more detail. Each time the 
processor determines via the on-board vehicle system that the vehicle has been 
turned off, it determines whether the reservation has ended. If the reservation 

15 has not ended, the system will continue to wait until the end of the reservation. 
If the processor determines that the reservation has ended, the status of the 
wireless connection is determined, as shown in step 603. If the wireless 
connection is not enabled, the system will wait until the connection is 
established (shown in step 602). If the connection is enabled, the processor 

20 sends the vehicle usage details, such as the start of usage, the end of usage, the 
card ID of the user, and the vehicle status to the zipcar.com server. 

Figure 7 describes Step D of Figure 3 in more detail. As shown in step 
701, the zipcar.com server receives usage information from the vehicle- 
associated access control module. As shown in step 702, charges for a 
25 particular use of the vehicle may be calculated based on a number of factors 
including which vehicle was used, from which parking location, for how long 
and at what time of day, the distance driven, which driver, and other system-set 
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parameters. As shown in step 703, the charges are automatically submitted for 
payment. 

Figure 8 shows the components of the overall system. The zipcar.com 
server 801 is connected to a database 802 that stores all the necessary 
5 information to manage the resource management reservation system. The 

zipcar.com server 801 is connected to the Internet 803 that allows a plurality of 
browsers 805, also connected to the Internet 803, to be used by the system of 
the present invention to reserve vehicles, view vehicle availability, review 
account status, report problems with vehicles, and perform other functions. A 
10 plurality of vehicle-associated access control modules 805 are also connected to 
the Internet 803 via a wireless link enabling communication between the on- 
board vehicle-associated access control modules 805 and the zipcar.com server 
801. 

When an authorized user, or driver, requests a reservation for a 
15 car, the system accesses the database 802 and registers in the database 
802, a reservation information item that represents the identity of the 
authorized user, the identity of the requested vehicle or vehicles, and the 
time requested by the reservation. When the system subsequently 
accepts, from a vehicle-associated processor 805, a request-to-access 
20 message indicating that the user is at a vehicle and is requesting access 
to the vehicle, the system responds by verifying the access request. The 
system, to perform verification, first determines the identity of the user 
requesting access to the vehicle. The system then compares the identity 
of the user requesting access to the vehicle, the identity of the vehicle, 
25 and the time of the request for access, against information contained in 
the reservation information item in the database. If the user requesting 
access is the user registered in the database and the vehicle is one of the 
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vehicles registered in the database, and the time of the request is also 
registered in the database, the system enables the user to access the 
vehicle. 

Figure 9 is an alternate embodiment of the system for shared use of a 
5 vehicle according to the present invention. In some cases, the wireless link to 
the vehicle-associated access control modules 905 may not be via the Internet 
903, but the connection may also be through some other network 906. This may 
be the case with the GSM network. The overall system and the other 
components are similar to that shown in Figure 8. 

q 10 Figure 10 shows the vehicle-associated access control modules system 

in more detail. As shown in Figure 10, the processor 1001 monitors vehicle 
m systems 1004, and determines various vehicle-specific facts, including whether 

•1! the engine is running or not, the odometer reading, the battery voltage level, and 

Q other vehicle-specific facts. The processor 1001 also monitors an on-board GPS 

^ 15 system and maintains the current location of the vehicle. The processor 1001 

□ also monitors the proximity or chip card detector 1005. The processor 1001 is 

\Z able to communicate with the zipcar.com Server via the wireless modem 1002, 

Tj which in this example is a CDPD modem, Novatel Wireless Expedite model 

2 and antenna 1003. The proximity or chip card 1013 is used to identify the 

20 driver and is detected by the proximity chip card detector 1 005. Processor 

1001 is able to enable and disable the vehicle ignition via ignition disable 1009. 
Processor 1001 is able to lock the doors via door lock 1010. Processor 1001 is 
able to unlock the doors via door unlock 1011. Processor 1001 is able to sound 
an alarm via speaker 1012. A user interface processor 1007 may be optionally 
25 connected to processor 1001 . This permits driver to enter data via keyboard 
1006 or other input device. This also permits the display of information to the 
driver via display 1008. 



20 



